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The purpose of this document is to illustrate, by means of a 
program testing application, the creation, use, and maintenance 
of user program libraries operating under the IBM System/360 
Operating System. The program testing application was chosen 
for illustrative purposes only and should not be construed as a 
workable system as it stands. The information in this text is 
based on information and components available at the time of the 
initial release of Operating System/360. The use of Assembler E, 
COBOL E, FORTRAN E, and Linkage Editor E is assumed. The 
user should therefore refer to the following texts and their most 
recent technical newsletters for the most complete, accurate, 
and up-to-date information: 

IBM System/360 Operating System: Utilities (C28-6586) 
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Cover and Preface Pages 

Add the following to the list of reference texts on both pages: 

IBM System/360 Operating System: System Control Blocks (C28-6628) 

Page 12 

In the drawing at top of page, change the word above the volume containing the SYS1.PROCLIB 
from "TESTVL" to "SYSRES". 

In the program listing below this drawing, add a comma at the end of the second line of item 4: 
"DISP=(NEW, KEEP), ". Similarly, add a comma at the end of the second line of item 5. The 
commas indicate continuation of the data definitions. 

Page 32 



In the Note at bottom of page, change the next to last line from: 

require an additional parameter, that is VOLUME=SER- TESTVL. 
to the following: 

require two additional parameters, that is, VOLUME=SER= TESTVL and UNIT-2311. 

Page 37 

Add "(see C28-6628) ,T to the end of the next to last paragraph. 
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PREFACE 



The purpose of this document is to illustrate the creation, use, and 
maintenance of user program libraries operating under OS/360. To 
facilitate the explanation of interplay and control among the various 
components of OS/360, the application of program testing has been 
chosen as a vehicle to demonstrate: 

Library creation and use 
Cataloged procedure creation and use 
Library maintenance 
Backup procedures 

The program testing application, hereafter referred to as TESTS, was 
chosen for illustrative purposes only and should not be construed as a 
workable system as it stands. The information in this manual is based 
on the information and components available at the time of the initial 
release of OS/360. The use of Assembler E, COBOL E, FORTRAN E, 
and Linkage Editor E is assumed. 

The user should therefore refer to the following texts and their most 
recent technical newsletters for the most complete, accurate, and 
up-to-date information: 

IBM System/360 Operating System Utilities (C28-6586) 

IBM System/360 Operating System System Generation (C28-6554) 

IBM System/360 Operating System Linkage Editor (C28-6538) 

IBM System/360 Operating System Job Control Language (C28-6539) 

IBM System/360 Operating System System Programmer's Guide (C28-6550) 
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DEFINITION OF A LIBRARY 



A 'library' is a partitioned data set (PDS), which is a data set with one or 
more sequentially organized members, residing on and not exceeding in 
space one direct access volume. OS/360 libraries may be categorized as 
follows: 

1. Libraries required by OS/360 for its operation , and residing on either 
the system residence volume or some other direct access volume. 

2. Libraries required when using certain processors or features of 
OS/360 (for example, the COBOL and FORTRAN libraries), but not 
required for the system to function. 

3. Libraries defined, organized, and named by the user to best 
accommodate the installation's requirements. 

The libraries falling in category 1 and referred to in this document are: 

SYS1. LINKLIB (Link library) 
SYS1.PROCLIB (Procedure library) 

Those falling in category 2 and referred to here are: 

SYS1.MACLIB (Macro library) 
SYS1.COBLIB (COBOL library) 
SYS1.FORTLIB (FORTRAN library) 

Full descriptions of these two categories may be found in C28-6554. 

Libraries in category 3 may be given simple or qualified names. Since a 
library is nothing more than a data set, it may be created during execution 
of any job step by defining the library name, allocating space on a volume, 
etc. (see "Library Naming and Creation"). While libraries in categories 
1 and 2 are neither created nor named by the user, they may be accessed 
and used as in category 3. 

User programs may be located in the Link library. To execute such a 
program, the user merely specifies the name of this program in the EXEC 
statement. 

User programs may also be located in a library created by the user 
(category 3). To execute a program in a user-created library, the user 
must define this library by inserting a data definition (DD) statement 
(with a ddname of JOB LIB) prior to the EXEC statement or statements 
requiring the use of this library. This DD statement causes OS/360 to 
search the identified user's library for the program to be executed before 
searching the Link library. 



OVERALL EXAMPLE - PROGRAM TESTING - "TESTS" 

In many installations the development and testing of applications 
consumes a great deal of effort and time. While testing systems vary 
from installation to installation, certain library maintenance methods 
should be followed to take full advantage of the computing system. 



The Test Cycle 



The sample testing system example, TESTS, is based on the concept of 
using a separate disk -pack exclusively for all program testing within an 
installation. The basic reason for this approach is to isolate undebugged 
programs and to ensure that they do not contaminate space on other 
packs or the system residence volume. 

TESTS is further thought of as a "stacked testing" procedure in which 
it is desirable to perform testing at convenient intervals during a shift 
and thus stack all tests to be performed, mount the TESTS pack, and 
perform the tests required. This approach will probably be valid for 
most OS/360 installations, at least in the early phases of their 
development. 

From an operations point of view, TESTS is thought of as an application 
in which the user may specify certain standard procedures to be 
performed in this test environment. 

From a programmer's point of view the tests performed on his program 
are done on a remote basis. The programmer must request the type of 
test he wishes. 

The TESTS system consists of three libraries, or PDS's. As shown in 
Figure 1, a library is available for each of the following: 

Source modules — programs in source language 

Object modules — compiled programs or subroutines 

Load modules — Linkage Editor output (executable programs) 

The programmer's first action is to request that his source module be 
entered into the source library. Once this is done, he may request one 
or more of the following: 

1 . Compilation 

2. Modification of his source program 

3. Linkage editing 

4. Execution 

5. Linkage editing to combine additional object or load modules 

6. Compile — linkage edit — execute 

Each of the modules (source, object, load) is retained in the appropriate 
library until the test cycle has been completed and the programmer 
wishes to remove it. 




EXECUTE 



1. Source code and modifications entered 

2 . Compilations 

3. Link-edit runs 

4. Program executions 



Figure 1. Libraries in TESTS system 



Overall Flow 



Thus the programmer debugs his program using computer output. He 
then updates and retests his program by requesting the appropriate 
phases mentioned above, without having to continually maintain a source 
deck throughout the complete compilation and testing cycle. 

Once his program has been thoroughly tested, he may request (among 
other things) the updated source deck, a listing, and the deletion of his 
program from the three TEST libraries. 



To illustrate the flow of operations that occur in the TESTS application 
environment, two examples have been given. Both consist of a diagram- 
matic representation of the job stream, the processing to occur, and the 
libraries used, as well as a description of the function of each statement 
in the job stream. The statements in the job stream are illustrative 
rather than actual. The actual job control language and control state- 
ments are specified in the detailed illustrations of each phase of the 
TEST application. 

The first example (Figures 2-5) illustrates the processing of A13, a 
source program that is to be placed in the source module library 
(TEST. SOURCE), assembled into an object module library 
(TEST. OBJECT), link-edited into a load module library (TEST. LOAD) 
and executed from TEST. LOAD. 

The second example (see "Multiple Job Flow in TESTS") illustrates the 
flow of multiple programs operating in the TESTS environment and is 
more meaningful as a summary of the contents of this document. 
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Job Stream 

Al. EXEC PROC=NEWSORC 

A2. ADDA13 
A3. Source Deck 



Processing Incurred 

Invokes cataloged procedure to place source 
program on source library (see Figure 9) . 

Indicates the name of the source program, A13. 

The source statements that are entered into 
TEST. SOURCE as A13. 



Figure 2. Job flow of one program from source to execution: source program to 
source library 
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FORTRAN 
ASSEMBLER 



OS/360 



TESTVL 




TEST. SOURCE 




AI3 



B3/7/ SYSPUNCH DD AI3 



B2X//SYSIN DD AI3 



Bl^// EXEC PROC = TESTASSM 



Job Stream 



Processing Incurred 



Bl. EXEC PROC=TESTASSEM 



B2. SYSIN DD A 13 (Input) 



Invokes the cataloged procedure to assemble 
the source module A13 (see Figure 13). 

Represents the DD statement indicating the 
name of the source module to be assembled. 



B3. SYSPUNCH DD A13 (Output) 



Represents the DD statement indicating 

that the member name A13 be assigned to the 

output object module to go into TEST. OBJECT. 



Figure 3. Job flow of one program from source to execution: source program in source 
library assembled into object library 
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Job Stream 



CI. EXEC PROC=TESTLINK 



Processing Incurred 

Invokes the cataloged procedure to link-edit the 
object module (see Figure 16). 



C2. INCLUDE A13 



Represents the Linkage Editor statement that 
specifies the name of the object module to be 
link-edited, A13. 



C3. NAME A13 



Represents the Linkage Editor statement that 
specifies the name to be assigned to the output 
load module going into the load library. 



Figure 4. Job flow of one program from source to execution: object module is link- 
edited and becomes a load module in the load library (TEST. LOAD) 
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Job Stream 



Dl. JOB LIB TEST. LOAD 



D2. EXEC PGM=A13 



*D3. OUTPUT A13 



*D4. INPUT A13 




TEST. SOURCE 



TEST. OBJECT 



AI3 




Processing Incurred 

Specifies to the control program that the 
program to be executed resides in the library 
named TEST. LOAD. 

Specifies the member name, A13, of the 
program in the library to be executed. 

Symbolically represents one or more DD 
statements required to specify the devices and 
data sets required for the output results of A13. 

Symbolically represents one or more DD 
statements required to specify the sources of 
input data for A13. 



*Must be specified by the programmer or set up as standard DD statements for input and 
output at the user's descretion. Note; It is not the intent of this document to stress test 
data set manipulation and control. 

Figure 5. Job flow of one program from source to execution: execution of program A13 



CREATION OF TESTS LIBRARIES 



Two phases are required before TESTS may be put into operation: 
(1) initialization and (2) library naming and creation. 



Volume Initialization 



In this phase the Independent Utility DASDI (see C28-6586) is used to 
create a volume label and to allocate space for the Volume Table of 
Contents (VTOC) . Figure 6 shows the control statements required for 
this phase. The volume serial number to be placed in the volume label 
is TESTVL. 



Library Naming and Creation 



Three libraries (partitioned data sets) are required in the TESTS 
environment (see note at end of this section) . They will be named: 

TEST. SOURCE — for source modules 
TEST. OBJECT — for object modules 
TEST. LOAD — for load modules 

Although the three libraries in the TESTS example are not cataloged, 
each library is assigned a two-element name. The reason for this is 
that someone else may wish to refer to a data set called SOURCE. To 
avoid duplication, the second person could call his library MY. SOURCE 
instead of TEST. SOURCE. 

It is apparent that all users of a test volume could have unique names 
for their libraries. However, if this were the case, each user would 
have to develop his own procedure or use the TESTS procedures and 
override certain DD cards. 

The approach taken in the TESTS example is a more standardized one 
permitting more accurate control, easier procedure specification, and 
more convenient maintenance of the TESTS volume. This standardization, 
however, requires the programmer to name his program according to 
some convention. 

A member (module) or program may have a name as large as eight 
characters. Without some type of naming convention, two independent 
programmers could name their programs by the same name — say, 
MATRIX. This would be intolerable, especially if both programs were 
expected to be in TESTS at the same time. Therefore, a naming con- 
vention must be established. For our example we will assign a two-digit 
code to individuals or departments. Thus department 23 will submit a 
program named MATRIX23 to TESTS. It must retain this name at least 
for the life of this program within TESTS. 



Figure 7 shows the job control statements required to allocate space for 
and create the three libraries as well as to enter a standard procedure, 
described in the following paragraphs, into SYS1.PROCLIB. It is 
desirable to develop standard procedures for the testing environment 
such as those for updating source modules, linkage editing, compiling, 
etc. , and to place these procedures in the procedure library 
(SYS1.PROCLIB). This document describes several of the procedures 
used in TESTS. 

Since the entering of a procedure into the SYS1.PROCLIB is a procedure 
itself, it will also be convenient to place that procedure in 
SYS1.PROCLIB. This procedure (called ADDPROCS) was initially put 
into the SYS1.PROCLIB via the UPDATE utility, as seen in Figure 7. 
The use of ADDPROCS for adding a procedure to SYS1.PROCLIB is 
illustrated in Figure 8. 

It is possible to add to or delete from a procedure in SYS1.PROCLIB 
through the UPDATE utility program. However, since a TESTS 
procedure would represent relatively few cards, a change to the proce- 
dure could also be accomplished by updating the original card deck. The 
updated procedure deck would then be added to SYS1.PROCLIB using the 
ADDPROCS procedure (Figure 8). Although the original procedure has 
the same name as the new one, the ADDPROCS will remove the pointers 
in SYS1.PROCLIB to the old one and point to the new procedure. 

Although not illustrated, all procedures for TESTS have been entered 
into SYS1.PROCLIB. Further references to these TESTS procedures 
will assume their residence in SYS1.PROCLIB. 

Note: Although not implemented in the TESTS examples, it would be 
advantageous to preallocate space for all utility (work) data sets — for 
example, SYSUT1 and SYSUT2 — at the same time that the TESTS 
libraries are created (see Figure 7). If this were done, space allocation 
for the utility (work) data sets would be avoided in subsequent procedures. 
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1. JOB 'INITIALIZE DISK ON 191 TO VQLIO=TESTVL« 

2. MSG TUDEV=1403, TGADDR=OOE 

3. CADEF TGDEV=2311,TGADDR=19i,VOLID=SCRATCH 

4. VLO NEWVOLID=TESTVLtCWNERIO=INSTLWCRK 

5. VTOCO STRTADR=0001,EXTENT=0009 

6. END 




Card 



Narrative 



1. 
2. 
3. 
4. 
5. 
6. 



JOB with comments. 

Messages will be printed on the printer. 

The specific pack to be initialized. 

The volume will be called TESTVL and owner is INSTLWORK. 

The VTOC will span nine tracks starting in cylinder 0, track 1, 

END card indicating end of JOB to the DASDI utility. 



Figure 6. To initialize the TESTS volume 
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1. 

2. 
3. 
4. 



5. 



SySJ?SS 



JCL 
THRU 9 
BELOW 




TESTVL 





T ES T 



•SOURCE 



T EST. OBJECT 



T EST. LOA D 



//INITAL 

// EXEC 

//SYSUT2 DD 

//SYSPRINT DD 

//DD1 DD 

// 

// 

//DD2 DD 

// 

// 

6. //DD3 
// 
//SYSIN 

7. ./ 
(V/PROC 

8. {//SYSUT2 



DD 

DD 
ADD 
EXEC 
DD 
(//SYSPRINT DD 
9. /* 



JOB 007,INSTLWORK,MSGLEVEL=1 
PGM=IEBUPDAT,PARM=NEW 
DSNAME=SYSl.PROCLIB,DISP=OLD 
SYSOUT=A 

DSNAME=TEST. SOURCE, VOLUME=SER=TESTVL, UNI T= 23 11, 
SPACE=(TRK, (50,10, 10) ),DISP= (NEW, KEEP). 
DCB=(,RECFM=F,BLKSIZE=80) 

DSNAME=TEST. OBJECT, VOLUME=SER= TESTVL, UNIT=231 1 , 
SPACE=(TRK,(U00,20,10)),DISP=(NEW,KEEP). 
DCB=(,RECFM=F,BLKSIZE=80) * 

DSNAME= TEST. LOAD, VOLUME=SER=TESTVL, UNI T=23 11, 
SPACE=(TRK,U00,20,10)),DISP=(NEW,KEEP) 
DATA 

ADDPROCS,01,0,1 
PGM=IEBUPDAT,PARM=NEW 
DSNAME=SYSl.PROCLIB,DISP=MOD 
SYSOUT=A 




1. 



2. 
3. 
4,5,6. 



7. 



9. 



Execute the utility UPDATE program (see C 28 -6 5 86) in order to enter into 

SYS1. PROC LIB a standard procedure for entering procedures into SYS1. 

PROC LIB. 

The data to follow will be put into SYS1. PROC LIB (SYSIN DD DATA). 

Required by the utility. 

DD cards which allocate space on TESTVL. Note that each library directory 

will handle 10x(4 to 7) members. Therefore, at any one time, a library 

directory can handle 10x6 (on the average) = 60 members. Note also that the 

actual number of modules that can be stored in a library depends on the size of 

the modules and the total space allocated to the data set. 

Control statement for IEBUPDAT. It names the member to be added. In this 

case it will be named ADDPROCS. 

The job control language for the procedure called ADDPROCS. 

Required by the utility and the control program. 



Figure 7. To create the TESTS libraries and add a procedure that will add procedures 
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1. //STEP EXEC ACDPROCS 

2. //PROC.SYSIN CD DATA 

3. ./ cPQ^ADD t.t.'^NEWSORCEtOltOt 1 



//KEtoSGRCE EXEC PGM=IEBUPOAT f PARM=NEW 

//SYSPRINT DO SYSQUT=A 

//SYSUT2 DP DSNAME=TEST. SOURCE, VOLUME=SER=TESTVL, 

// UNIT = 2311,DISP=OLD . 





1. Executes the ADDPROCS procedure (see Figure 7) for entering a procedure into the 
SYS1.PROCLIB. 

2. DD * statement for the ADDPROCS procedure — that is, the member (s) follows. 
Note; the DD name must be qualified with the step name of the procedure . The step 
name is PROC (see Figure 7). 

3. Required by the utility UPDATE (see C28-6586) . The NEWSORCE name will be the 
name of the member (procedure) that will be added. 

4. The job control cards that will be entered as a procedure. 

5. Required by the utility and the control program. 

Note; Any procedure may be added in this manner. If multiple procedures are to be 

added with one EXEC ADDPROCS, the ADD cards (with the procedure names and 
associated job control statements to be entered) must be in binary collating 
sequence. 



Figure 8. To add a procedure to SYS1. PROC LIB with ADDPROCS 



13 



UTILIZATION OF TESTS 
Source Library 



The library called TEST. SOURCE contains source modules. Each 
module is in source code (Assembler, FORTRAN, COBOL, PL/l). 
The original source code is entered into the TEST. SOURCE PDS once. 
After errors are detected via the debugging cycle, the programmer 
requests changes to his source code. This method eliminates 
voluminous card and tape handling since the source code is always on 
disk. 

SOURCE MODULE CREATION 

By executing the NEWSORCE procedure, any set of symbolic coding may 
be entered into the TEST. SOURCE library. This source coding then 
becomes a member of the source library, with a program name specified 
by the programmer. Figure 9 illustrates this method. Note that 
NEWSORCE assigns a sequence number to each source statement. This 
sequence number can be referenced by the programmer when making 
changes to the source module. 

SOURCE MODULE CORRECTION 

After a debugging run, changes to the original source code may be 
needed. The procedure CHGSORCE allows the programmer to specify 
which original source statement(s) he desires to have deleted (if any) 
and whether he wishes new source statements added to the original source. 

A standard TESTS form is illustrated to allow the subsequent additions 
and deletions of source code (see Figure 10). The implementation of 
these changes is shown in Figure 11, and the listed results indicating 
what took place is shown in Figure 12. 

Object Module Creation 

Once the source modules have been entered on TEST. SOURCE, they are 
processed by one of the language translators (Assembler, FORTRAN, PL/I, 
or COBOL). The output of a language translator is defined as an object 
module, which in this application becomes a member in the object 
library (TEST. OBJECT). 
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SOURCE CODE MODULE 



NUMBR 00000000? 00000000* 00000010? 0000001 



ADD B13i01»0j1 
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SYS IN DD DATA 
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i i ii 
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ii 
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CC72 



//NEWSORCE EXEC PGM= IE8UP0AT ,PARM=NEW 
//SYSPRINT DO SYSOUT=A 

//SYSUT2 DD DSNAME=TEST-SOURCE f VOLUME=SER=TESTVL, 
// UNIT=2311,DISP=OLD 



4 



1. Execute the NEWSORCE procedure. 

2 . NEWSORCE procedure in SYS1 . PROCLIB . 

3. Name the added member B13. 

4. Sequence -number the source code, starting at 10 and incrementing by 10. 

5. Symbolic code to be entered into TEST. SOURCE. 

6. Required by IEBUPDAT (C28-6586) and reader-interpreter. ( Note; Source code 
for multiple members may be entered with one EXEC NEWSORCE; however, the 
ADD card with the member name and associated source code must be in collating 
sequence by member name.) 



Figure 9. To enter symbolic (source) module into the source library 
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Figure 10. Form for entering changes into the source library 
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1111111111111111111111111111111111111111111 

2 222222 2 2 2 |2 2 2 2 2 2 2 2 2 2 22222 22 222 2 22222 22 22 2 2| 222222222 



000000000 

72 73 74 75 76 77 78 79 80 
111111111 



TESTVL =>■ 




^ 7 mmm^^ 




REMOVE. 



SYS1.PROCLIB 



MERGE 
OS/ 360 



CH&ORCE 



2. 



//CHGSORCfc EXEC PGM=IEBUPDAT f PARM=MOD 

//SYSPR1NT DD SYSOUT=A 

//SYSUT1 DD DSNAME=TEST.SOURCEtVOLUME=SER=TESTVLt 

// UNIT=2311,DISP=OLD 

//SYSUT2 DD DSNAME=TEST. SOURCE, VOLUMh=SER=TESTVLt 

// UNIT=2311,DISP=0LD 



1. 
2. 
3. 

4. 
5. 
6. 



Invoke the CHGSORCE procedure. 

CHGSORCE JCL in SYS1 . PROC LIB . 

Name of the program (member) to be changed — in this case B13. 

Specified deletions of 80 -character records and source code to be added. 

Required by IEBUPDAT (C28-6586) and the Interpreter. 

This DELET card is not required since both the old 1970 and 1980 

would be automatically deleted and replaced by the new 1970 and 1980 

source statements. 



Figure 11. To make corrections to the source library 
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I- 4 

00 



SOURCE LIME INSERTED 



SUURCE LINE DELETED 
SOURCE LINE DELETED 
SOURCE LINE INSERTED 
SOURCE LINE INSERTED 



SOURCE LINE DELETED 



WK i "4 c i o» o J" 

605 FGRMAT(2I3,4F10.2) 
IYK=IYR+1 

1 = 1 

GO TO 603 
C 

C BALANCE DUE IS LESS THAN MONTHLY PAYMENT 
C 

606 PAYPRN=AMGUNT+PAYPRN 
AMOUNT=0. 

./ DELET 00001970,00001980 

WRI TE { 5, 600 ) MO, I YR, PA YPRN, PAY INT, TOD ATE, AMOUNT 
wRITE{5,602) 

WRITE<6,605)MO,IYR,PAYPRN,PAYINT,TGDATE,AMOUNT 
WRITE ( 6,60 7] 

607 FORMAT( , 0*/»0***** LOAN AMORTIZED *****«/• Q* /• •/• • ) 
CALL CLGCK(ITIME) 

IDELTA={ I FIMES-i TIME)/ 76800 

IF UOELTA) 710,720,710 
710 WRITE (6,999) IDELTA 

999 FORMAT {• TOTAL TIME = »,M0,» SECONDS') 
./ DELET 00002050,00002050 
720 PAUSE 99999 

GO TO 1 

END 



ABOVE NAMEIB13 



I FOUND IN NM DIRECTORY, TTR IS NOW ALTERED 



END OF JOB, •/ ENDUP READ 
******** HIGHEST CONCODE IN PROGRAM WAS 00 



0000190( 

opnniqia 

Q000191p 

ooouiyiTo 

00001930 
00001940 
00001950 
00001960 

00001970 s 
£p00198Q> 

tn 

,30001980^ 
0( 

00002000 
00002010 
00002020 
0000203.0 
00002040 

,00002050; 
OOlKTZTJSO 
00002070 



Figure 12. Results of source correction 



A cataloged procedure named TESTASSM, using the assembler as the 
language translator, compiles a source module from TEST. SOURCE 
into an object module. The name of each of the input source modules 
from the source library, and the names of each of the output modules 
to be entered in the object library (TEST. OBJECT), are specified in 
the job stream for each language translator job step. This procedure 
and the required DD statements specifying input and output are 
illustrated in Figure 13. Similar procedures may be executed for 
FORTRAN and COBOL (see Figures 14 and 15). 



Load Module Creation 



Object module output from language translators is in relocatable, but 
not executable, format. Therefore, before execution, the object 
modules must be processed by Linkage Editor so that they may become 
executable load modules. In addition, adhering to OS/360's basic 
concept of modularity, modules that have been separately tested may 
be combined by the Linkage Editor. Also, any editing or overlay 
structuring of existing object or load modules is done at this time. 
Because in this application all object modules are in TEST. OBJECT and 
all load modules are in TEST. LOAD, each has access to the others in 
the TESTS environment, easing considerably the difficulties in locating 
modules. 

While the linkage editing can be done on a compile -linkage edit-execute 
basis for each program to be tested within the TEST environment (see 
Figure 18) , the procedure to be discussed here addresses itself to a 
single Linkage Editor run during which multiple load modules are 
created, thereby reducing the number of times the processor is brought 
into core storage. 

Once the programs to be tested are in the TEST. OBJECT library as 
object modules, they will be link-edited via the cataloged procedure 
TESTLINK, onto the load module library (TEST. LOAD). This, then, 
allows the programmer to reference these libraries for any additional 
modules he may require by use of the Linkage Editor INCLUDE statement. 

As illustrated below, the job stream for the Linkage Editor run, contains 
(1) an EXEC statement calling for execution of the cataloged procedure 
TESTLINK, (2) a DD * statement named TESTLINK. SYSLIN, which 
indicates that the input specifications to Linkage Editor will follow in 
the job stream, and (3) a set of Linkage Editor control statements 
specifying the names of the input and output modules of each load module 
to be created. 

// EXEC PROC=TESTLINK 
// TESTLINK. SYSLIN DD * 

INCLUDE OBJPDS (object module name 1) 

NAME load module name 1 (R) 

INCLUDE OBJPDS (object module name 2) 

NAME load module name 2 (R) 
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JOB STREAM 



S. 



//TESIASSM.SYSPUNCH OD DSNAME=TEST«OBJECT( A13) 



7. 



/ ^ f / //I£STASSM.SYSlN 



DO 0S(SAME=TEST,S0URCECA13> 



//.ST EPA 



EXEC 



PRCOTESTASSM 



3. 




OS/ 360 
ASSEMBLER 










AI3 











TEST. OBJECT 





SYSi. PROCLIB 



//TEST.ASSN 

//SYSUT1 00 

// 

//SYSUT2 DO 

// 

//SYSCT3 00 

// 

//SYSPRINT DD 

//SYSL1B 00 

// 

V/SYSiN 00 

// 

//SYSPUNCH CO 

// 



EXEC PGfc=IETASM C.C.72 v 

OSNAM£=UTX ,UNIT=2311tSPAC£=<TRK,C5Q,10)), J 
VOLUME=SER=T£STVL 

DSNAH£=UTY f UNIT=2311»$PACE=(TRK,(50,10))» * 
VQLUKE=S£R=T£STVL 

DSNAME=UTZ, 0NIT=2 311,SPACE=( IRK , (50, 10 ) ) f * 
VOLUWE=SER=T£STVL 
SYS00T=A 

DSNAM£=SYS1.MACLI8, UNIT=2311 ,0ISP=0LD, * 
VOLUME=SER=illIll 

DSNANE=TESr.SGURCE,UNIT=2311,0ISP=0LD, * 
VOLUME=SER=TESTVL 

D$NAME=TEST.GBJECT,UNIT=2 311,DISP=GLD, * 
VOLUME=SER=TESTVL 



Underlined parameters are not necessary. 



Figure 13. To compile or assemble a source module from the source library into the 
object library 
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1. This EXEC statement in the job stream invokes the cataloged, 
procedure TESTASSM. 

2. This EXEC statement invokes the assembler IETASM. 

3. Three DD statements defining the space and volume (TESTVL) on 
which the three utility data sets required by the assembler should 
be allocated. 

4. SYSPRINT specifies that the assembly listing should be printed. 

5. This SYS LIB DD statement specifies that SYS1.MACLIB, which is 
required for the assembler, resides on the system residence volume, 
111111. 

6. SYSIN specifies the name of the library (TEST. SOURCE) containing 
the input source modules, which will be used as input to the 
assembler or compiler, and indicates that this library resides on 
TESTVL. 

7. TESTASSM. SYSIN specifies the name of the source module (A13) to be 
assembled from the library and overrides the parameter in 6. 

8. SYSPUNCH specifies that the library named (TEST. OBJECT) residing 
on TESTVL is the library in which the object modules are to be 
placed. 

9. TESTASSM. SYSPUNCH specifies that the name of the object module 
to be placed in TEST. OBJECT is A13 and overrides the DSNAME 
parameter in 8. 



Figure 13 (continued), 
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SYS1.PR0CLIB 



CC72 

i 



// TESTFORT EXEC PGM=IEJFAAAO,PARM=« SI ZE=500G0 • 
//SYSPRINT OD SYSQUT=A 

00 DSNAtt£ = (iTl , UNI T=23 1 i , SPAC£= { TRK ,(30,10)), 

VOLUME=S£R=TESTVL 
CD DSNAyE=UT2 ,UNIT=2311,SPACE=(TRK,(3Q,10) ), 

VGLUM£=SER=TESTVL 
CO DSNAM£=TEST.SQURCE,UNIT=2311,DISP=GLD, 
VGLUNE=SER=TESTVL 




Job stream to execute FORTRAN procedure 



//TESTFORT, SYSLIN DD DSNAME*TEST. OBJECT ( B13) 



//TESTFORT. SYSIN 



DO DSNAME=TEST. SOURCE* B13) 



EXEC 



PRGC=TE$TFGRT 



SPECIFY THE NAMES 

OF THE INPUT AND OUTPUT 

MODULES FOR FORTRAN 

Figure 14. To create object modules using TESTS cataloged procedure for FORTRAN 
SYS1.PR0CLIB 



i 



//TESTCGBL 




EXEC PGM=IEPCBL00 




//SYSUT1 


00 


DSNAME=UTA,UNIT=2311,SPACE=(TRK,{40,10)), 


* 


// 




VGLUME=SER=TESTVL 




//SYSUT2 


CD 


DSNAME=UTB,UNlT=2311,SPACE=lTRK,(40,10)) f 


* 


// 
//SYSUT3 


DD 


VGLUME=SER=TESTVL 


* 


DSNAME=UTC,UNIT=2311,SPACE=(TRK,(40,10)), 


// 




VCLUME=SER=TESTVL 




//SYSPRINT 


00 


SYS0CT=A 




//SYSIN 


CO 


0SNAME=TEST.SUURCE,UNIT=2311,DISP=GLD, 


* 


// 




VGLUME=SER=TESTVL 




//SYSPUNCH 


DD 


DSNAME=TEST.GBJECT,UNIT^2311,DISP=GLD, 


* 


// 




VGLUME=SER=TESTVL 





Job stream to execute COBOL procedure 



//TESTCGBL. SYSPUNCH 00 DSNAM£=TE ST. OBJECT CC013) 

: : y 



//TESTCGBL. SYSIN 



DO OSNAM£=TEST. SOURCE (CD 13) 



EXEC 



PRGC=T£STCOBL 




Underlined parameters are not necessary, 



SPECIFY THE NAMES 

OF THE INPUT AND OUTPUT 

MODULES FOR COBOL 



Figure 15. To create object modules using TESTS cataloged procedure for COBOL 
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To combine additional object modules in a load module, their names may 
be specified in one INCLUDE statement (see item 1 below), or additional 
INCLUDE statements may be inserted (see items 2 and 3 below). 

1. INCLUDE OBJPDS (name 1, name 2, name 3) 

2. INCLUDE OBJPDS (name 2) 

3. INCLUDE OBJPDS (name 3) 

Load modules from the load library may be combined with other modules 
as follows: 

INCLUDE SYSLMOD (load module name or names) 

Additional specifications for each load module may be inserted between 
the INCLUDE and NAME statements. If more than one module is to 
comprise the load module, an ENTRY statement specifying the entry 
point to be assigned to the load module should immediately precede the 
NAME statement. 

Any Linkage Editor control statements to create an overlay structure or 
to edit the modules should be placed in the job stream preceding the 
NAME statement as specified in the Linkage Editor manual (C28-6538). 

The Linkage Editor procedure in Figure 16 (TESTLINK) produces a 
module map and a list of all Linkage Editor control statements. If 
additional or different processing options are desired, all parameters 
required should be specified in the EXEC card, as shown in Figure 16. 

FORTRAN and COBOL object modules require that SYS1.FORTLIB 
and SYS1.COBLIB respectively be specified as the Linkage Editor 
automatic call library (SYSLIB) (see C28-6538). Therefore, they have 
been concatenated in the TESTLINK procedure. 
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CC72 

i 



EXEC PGM=LINKEDIT,PARK=«MAP,LIST' 

DSNAME = SYSl.FORTLIBt UMT = 2311 ,PISP=OL0, 

DD DSNAME=SYSl.C0BLiB, UNlT=231 1,DISP=0LD, 

VGLUNE = SER=1U111 

DSNAME=LTl f UNIT=231i,SPACE=(TRK,(60,10)), 

VOLUME=SER=TESTVL 

SYSOUT=A 

DSNAME= TEST. OBJECT, UN I T=2311,DISP=0LD f 

VOLUME=SER=TESTVL 

DSNAME=TEST.LOAD,UNIT=2 311,DISP=GLD, 

VGLUME=SER=TESTVL 



1. The EXEC statement in the job stream invokes the cataloged 
procedure TESTLINK. PARM. TESTLINK='XREF, LIST, LET' 
overrides the PARM field in the EXEC statement of the cataloged 
procedure and will cause a cross-reference listing to be produced 
instead of a memory map and put into effect the processing option 
LET. 

2. The EXEC statement invokes Linkage Editor and specifies processing 
options MAP and LIST (in this example they were overridden) . 

Figure 16. To linkage-edit multiple load modules in one Linkage Editor run 
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3. SYSLIB defines the automatic call library to Linkage Editor and con- 
catenates SYS1. FORTLIB and SYS1. COB LIB. This allows any 
object modules to be processed, whether compiled by COBOL or 
FORTRAN. 

4. SYSUT1 specifies that the Linkage Editor's utility (work) data set be 
allocated space on the volume TESTVL. 

5. SYSPRINT specifies that the diagnostic messages, memory map, and 
a list of Linkage Editor control statements processed should be 
written on the printer. 

6. This DD statement indicates that any reference to OBJPDS in Linkage 
Editor control statements will refer to the object library (TEST. 
OBJECT), which resides on volume TESTVL. 

7. The SYSLMOD DD statement specifies that all load modules created 
by Linkage Editor in this run will be placed in the load library 
(TEST. LOAD), which resides on the volume TESTVL. 

8. This specifies that the primary input data (SYSLIN) follows 
immediately in the job stream. 

9. This Linkage Editor control statement specifies that there are two 
members, A13 and SUBA13, in the library specified by the DD 
statement named OBJPDS that will be the input to this load module. 

10. This control statement specifies that the name of the first load module 
to be placed in TEST. LOAD is ASUB13. 

11. This control statement specifies that the input to the second load 
module is the member named Bl 3 on TEST. OBJECT. 

12. This control statement specifies that the name of the second load 
module to be entered in the load library is B13. 

13. This statement specifies that member D13 on TEST. OBJECT will be 
part of the third load module. 

14. This specifies that C13, previously link-edited and on TEST. LOAD 
(indicated by the SYSLMOD DD statement, which points to that library) 
is to be combined with D13 as input to the third load module. 

15. This ENTRY statement assigns an entry point named START to the 
load module. 

16. This NAME statement assigns the module name CD13 to the load 
module containing C13 and D13 on TEST. LOAD. 

17. /* denotes the end of the Linkage Editor input. 



Figure 16 (continued), 
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Execution of Load Modules 



Because all of the load modules now ready for execution are in the library 
named TEST. LOAD, the JOBLIB DD statement required for execution 
of each of the load modules to be tested is the same (see "Definition of a 
Library"). Therefore, the job stream required to execute any load 
module will contain a JOB card, a JOBLIB DD statement pointing to 
TEST. LOAD, an EXEC statement where PGM='member name to be 
tested', followed by the appropriate DD statements for that particular 
program. (See Figure 17 for an illustration of a job stream to test 
programs in TEST. LOAD). While it is possible to test multiple load 
modules in one JOB, each as a separate job step, all using only one 
JOBLIB statement, it should be noted that once an abnormal end of one 
execution is encountered, the ensuing job steps will be bypassed. 



14 

13 
12 

1 1 
10 
9 



//IN 




//OUT 



CO SYSGUT=A 



VGLUNE=SER=TESTVL 



00 DSNAME=DATA(GNE) ,UNIT=2311,DISP=0LD, 



EXEC 



PGM=F13 



-\ 



. C.C.72 



/GUTFILE DO SYS0UT=A 



//INFILE DO DSNAME= INPUT, UNI T= 12400,, DEFER ) ,LA8EL= ( ,NL) 

" TESTVL 





//JGBLId 00 DSNAME=TEST. LOAD, UNIT=231 1 ,01 SP=( OLD, PASS), * 



I /V/JCBO JOB C07,TESTEXEC,MSGL£VEL=1 
Figure 17. To test programs from the load library 



C.C.72 
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1. The JOB statement indicates that a new job, JOBD, follows. 

2. JOBLIB indicates that before searching the Link library for the 
programs to be executed, the library TEST. LOAD on volume TESTVL 
should be searched. 

3. The EXEC statement causes the program ASUB13 to be executed. 

4. This DD statement indicates that the output (assigned the ddname 
OUTPUT by the programmer) of ASUB13 is to go on the printer. 

5. This DD statement specifies that the input data (INPUT) for ASUB13 
follows in the job stream. 

6. The second job step indicated by this EXEC statement causes program 
B13 to be read into core from TEST. LOAD and executed. 

7. FT03F001 is the ddname assigned by FORTRAN to the output data 
set for B13, the printer. 

8. FT01F001 is the ddname assigned by FORTRAN to the DD statement 
that specifies that B13's input data follows in the job stream. 

9. The third job step causes program CD13 to be executed. 

10. INFILE specifies that the input data set for CD13, INPUT, is on tape. 

11. OUTFILE specifies that the results of CD13 are to be printed. 

12. The fourth job step causes program F13 to be executed from 
TEST. LOAD. 

13. IN, the ddname defining the input data set for F13, indicates that it 
is a member named ONE in the PDS named DATA. 

14. OUT specifies that the results of F13 are to be printed. 



Figure 17 (continued). 
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Job Stream 



COMPILE 



LINKEDIT 



//TESTPROC JOB 007JNSTLTEST, MSGLEVEL=1 
// EXEC PROC=® 

// ® .SYSINDD DSNAME=TEST. SOURCE (®) 

7/ ® •© DDDSNAME=TE ST. OBJECT (®) 

// EXEC PROC=TESTLINK,PARM.TESTLINK= T 

//TESTLINK.SYSLIN DD* 

INCLUDE OBJPDS (®) 

NAME ® ( R ) 

/* 



©' 



EXECUTE 



//TEST B JOB 007,INSTLEXEC,MSGLEVEL=1 
//JOBLIB DD DSNAME=TEST. LOAD, DISP=(OLD, PASS). 



// 

// © 

// © 

/* 



VOLUME=SER=TESTVL 
EXEC PGM =© 
DD 
DD 



@ = Language Procedure Name 

FORTRAN PROC=TESTFORT 

COBOL PROC=TESTCOBL 

ASSEMBLER PROC=TESTASSM 
® = Member name, that is, name of program to be compiled 
© = Compiler output ddname 

FORTRAN SYSLIN (See Figure 14) 

COBOL SYSPUNCH 

ASSEMBLER SYSPUNCH 
= Optional Linkage Editor parameters 

= Member name to be assigned to load module. E may equal B 
= DD statements required to specify input and output data sets for 
execution of the program. 



Figure 18. Generalized compile-Linkage-Edit — Execute procedure 
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LIBRARY MAINTENANCE 



Three types of maintenance are required to keep the three libraries 
(source, object, load) to a manageable size: 

1. Reducing the PDS's extent requirements 

2. Purging unused members 

3. Punching, listing, and deleting completed programs 



Reducing Extent Requirements 



The frequency with which the installation would wish to reduce the 
extents of a PDS depends on the volume of testing being performed and 
the original size of the PDS. Additional extents may be required, as 
new members (programs) are added or updated in a library. As an 
example, if a source program named MATRIX13 were originally put 
into the source library and subsequently changed through the CHGSORCE 
procedure, the original space for the MATRDQ3 module would be 
unavailable for use. 

Probably on a shift basis or daily basis , the installation would want to 
obtain a picture of the situation. In order to do this, a procedure is 
included here called TESTPEEK. This procedure allows the printing 
of the TESTVL Volume Table of Contents, and the contents of each 
library. Figure 20 illustrates the TESTPEEK procedure. Note that 
only one card is required in the job stream to obtain the listings, 
because the control statements for the utility IEHLIST are located in 
SYS1.PROCLIB, cataloged under the name CNLPEEK2. The control 
statements are called by the SYSIN DD statement in TESTPEEK, which, 
of course, is also in SYS1.PROCLIB. An examination of the output, 
with particular attention to the number of extents in each library, may 
lead to the decision to reorganize the libraries if they contain much 
space that is unavailable for use. 

To perform this function, we MOVE (see C28-6586) the TESTVL 
volume to itself. This particular utility program for each PDS specified, 
examines the directory and moves it to the new PDS. It also places the 
members in the top of the new PDS as illustrated in Figure 19. 

To perform this for all the partitioned data sets on the entire TESTS 
volume, a procedure called CLEAN can be used, which is illustrated 
in Figure 21. Note that again only one card is required in the job stream 
to perform the CLEAN procedure, because both the CLEAN procedure 
and the IEHMOVE control statement required by it are on SYS1.PROCLIB. 
The SYSIN DD in CLEAN calls the control statement which is cataloged 
under the name CLEAN1. 
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OLD PDS 



MOVED PDS 



DIRECTORY 



UNAVAILABLE 
SPACE 




AVAILABLE 
SPACE 



B 



Figure 19. Increasing the available space in a PDS 



Purging Unused Members 

From the listing received from the TESTPEEK procedure, it will be 
desirable to audit the usefulness and timeliness of the various modules 
(programs) . 

If it is determined, for instance, that a particular module is no longer 
useful, the installation may run the utility IEHPROGM and scratch a 
particular member from all libraries. A procedure for this has not been 
included in this document, but it could be similar to the last three steps 
in the SORCEDOC procedure (see Figure 22) . 

Completed Programs 

After a program has completed its required testing and is performing 
satisfactorily, it can be (1) moved to LINKLIB or a specific JOB LIB; 
(2) used to obtain a copy on tape or cards, or to obtain a listing; etc. 

One of the most common joint functions performed on a completed 
program would be to (1) list the source code, (2) punch a source deck, 
and (3) delete the program member from the source, object, and load 
libraries. The SORCEDOC procedure, (see Figure 22) together with 
the cataloged control statements that are also in SYS1.PROCLIB (see 
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Figure 23) will perform all these functions. To reduce the number of 
cards required in the job stream (only four are required to print and 
punch a program while deleting it from three libraries) , the SORCEDOC 
procedure uses several features of OS/360: 

1. The ability to execute a multiple-step procedure. (SORCEDOC 
contains a number of EXEC statements.) 

2 . The ability to call utility control statements from a library rather 
than placing them in the job stream. 

3. The ability to specify that a sequential data set is to be concatenated 
with a PDS member, and the ability to continue a utility control 
statement. (See "Data Set Utilities" in C28-6586 for concatenation 
restrictions.) 

In this case (Figure 22) the name of the program to be printed, punched, 
and scratched (entered in the job stream) is recorded in a newly created 
temporary data set called TEMP (see point 1 in Figure 22) by the utility 
IEBGENER. This temporary data set then supplies the name of the 
program to the other utility programs in SORCEDOC. Note that the 
SYSIN DD statements in steps 2-6 of SORCEDOC call a utility control 
statement (a member of a PDS) from SYSIN. PROC LIB. The following 
DD statement, since it has no ddname, concatenated this temporary 
data set with the control statement. Also note that each utility control 
statement is prepared with an = sign in cc 71 (following MEMBER or 
MEMBER NAME) and a continuation indicator in cc 72. Therefore, each 
utility in steps 2-6 of SORCEDOC looks for the member name in TEMP 
after reading the = sign of the control statement. (See Figure 24 for a 
detailed illustration of the concatenation of the data sets and continuation 
of the utility control statement.) 

Further, it is important to observe that to print /punch a member using 
the utility Print/Punch program, the detailed statement must be written 
MEMBER NAME = XXXX. In the IEHPROGM utility, to scratch a 
member, it must be specified as. . . , MEMBER = XXXX. 

One of the most important features of the SORCEDOC approach is that 
it protects the user from inadvertently scratching a library. If, for 
example, a nonexistent member is specified or a member specification 
was omitted from the job stream, the utility will not scratch the library, 
since no member name was specified for the MEMBER or MEMBER 
NAME parameter. 
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// EXEC TESTPEEK 




///PEEK2 EXEC PG*=IEHLISJ 
W/SYSPRINT OD SYSOUT=A 
2)//DDl DD VOLUME=SER= TESTVL, UNI T= 23 11, DISP=OLD 

(//SYSIN DD DSNAME=SYS1.PR0CLIB(CNLPEEK2),DISP=0LD 



^ 



HZ 

3.< LI 



STVT.GC VGL=231i=TESTVL 

STVTGC DUMP,VGL=2311=TESTVL 

STPDS VGL=2 3 1 1=TESTVL, DSNAME=TEST. SOURCE 

LISTPDS VOL=2311=TESTVL,DSNAME=T£ST. OBJECT 

Li STPDS VGL = 2 311 = TESTVL,DSNAME = T£ST<.LGAD 



1. 
2. 
3. 



4. 



"TEST- 
SYSTEM 
CONTROL 



Only one card required to obtain listings. 
The procedure TESTPEEK located in SYS1. PROCLIB. 
The control statements for the utility IEHLIST to list the desired data. 
Note that these five statements are located in SYS1. PROCLIB under 
the name CNLPEEK2. These statements are called by the DD State- 
ment in TESTPEEK. A SYSIN DD * cannot reside in a cataloged 
procedure. 
Output results . 



Note: In the TESTs environment it would be desirable to have the 

SYS1. PROCLIB on the TESTVL volume. This would allow the 
procedures for TESTs to be mounted only when the testing is in 
process and would leave system residence SYS1. PROCLIB space 
open for more universal procedures. It should be noted, however, 
that if the SYS1. PROCLIB were on TESTVL and pointed to at IPL 
time, DD cards in this writeup that reference SYS1. PROCLIB would 
required* additional parameter* that is, VOLUME=SER«TESTVL. ( 
This would eliminate a catalog search. 



(hNtr*(2JJ/ 



Figure 20. To list TESTS system control data 
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//CLEAN EXEC 
//SYSPRINT DO 
//SYSUT1 DO 
//0O2 00 



PGM=IEHMOVE 
SYSGUT^A 

UNlT=231i,VGLUME=SER=llllli t DISP=GLD 
UNIT=2311, VGLUME=SER=TESTVL,DISP=QLD 



//SYSIN OD DSNAME = SYS1.PRGCH6<CLEAN1),DISP=0LD 



3. MOVE VGLUM£=2311=TESTVL,TO=23U = TESTVL 



NOT C.C.I 




1. One card required to invoke the CLEAN procedure. 

2 . The C LEAN procedure is located in SYS1 . PROC LIB . 

3. Control statement for the utility IEHMOVE located in SYS1. PROC LIB under the name 
CLEAN1. This single statement moves TESTS volume to itself. 

4. Conceptually, the action that takes place. The running time depends on the number of 
data sets and members within the data sets. The old data sets are deleted. 



Figure 21. To reduce extent requirements on a volume 
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'/ * 



RECORD FIELD=(80,I„I) 



CC16 

AI3 



/7/ SORCEDOC. SYSUT1 DD * 
/// EXEC SORCEDOC 




TESTVL 




TEMP 



PROGRAM 
LISTING 



rV 



SYSi.PROCLIB 



PROGRAM 
PUNCHED 




//^URCEDQC EXEC PGM=IEBGENER 

//SYSPRINT DD SYSOUT=A 

//SYSUT2 DD DSNAME = TEMP,UNtT=23ll,VOl.UME=SER = TESTVL,DISP=(NEW,K£EP), * 

// DCB=< ,RECFM=F,BLKSIXE = 80).,$PACE = (TRK,{2) ) 

// SYSIN DD D UMMY 
/ //SI EXEC PGM=IEBPTPCH 
[ //SYSPRINT DD SYSOUT=A 

1 //SYSUT1 DD DSNAME=TEST. SOURCE, VOLUME=SER=TESTVL, «--7^^^ * 

2.< // UNIT=23ll,DlSP=OLD 

j //SYSUT2 DD SYSOUT=A 

f //SYSIN DD DSNAME=SYSl.PROCLIB<PRTSORCl),DISP=OLD 
V __// PD. D_SNAME = TEMP,VOLUME=SER=TESTVL,UNIT=231l,DlSP=OLD 

//S2 EXEC PGM=IEBPTPCH 

//SYSPRINT DD SYSOUT=A 

//SYSUT1 DD DSNAME = TEST, SOURCE, VOLUME = SER = TESTVL, X _.. X * 

// UNIT=23U,DISP=QLD 

//SYSUT2 DD UNIT=OOD 

//SYSIN DO DSNAME=SYSi.PROCLIB(PCHSGRCl),DISP=OLD 
_/_/ DD DSNAME=TEMP,VOLUME=SER^TESTVL,UNIT=23Il,DISP=OLD 

//SCH1 EXEC PGM=IEHPROGM 

//DD1 DD V0LUME=SER=TESTVL,UNIT=231i,DISP=0tD 

//SYSPRINT DD SYSOUT=A 

//SYSIN DD DSNAME=SYSl.PROCLIB(SCHSORCE),DISP=OLD 
J I DO DSNAME_=TEMP,VOLUME=SER=TESTVL,UNIT=23ll,DISP=OLD 

//SCH2 EXEC PGM=IEHPROGM 

//DD1 DD VOLUME=SER=TESTVL,UNIT=23il,DISP=OLD 

//SYSPRINT DD SYSOUT=A __ 

//SYSIN DD DSNAME=SYSl.PR0CLIB(SCHOBJCT),DISP=OLD 
_// DD pSNAME=TEMP,VOLUME=SER=TESTVL,UNIT=2311,DISP=OLD 

//SCH3 EXEC PGM=IEHPROGM 

//DD1 DD VOLUME=SER=TESTVL,UNlT=23ll,DISP=OLD 

//SYSPRINT DD SYSOUT=A 

//SYSIN DD DSNAME=SYSL.PROCLIB{SCHLOADT),DISP=OLD 

// DD OSNAME=TEMP,VOLUME=SER=TESTVL,UNIT=2311,DISP=(OLD,DELETE) 





A. JCL required to execute procedure SORCEDOC. 

1. Brings program name (in this example, A13) from card reader and stores it in a 
newly created sequential data set called TEMP. 

2. Prints program — A13 (source). 

3. Punches program — A13 (source). 

4, 5,6. Scratches member A13 from TEST. SOURCE, TEST. OBJECT, TEST. LOAD, 
respectively. 



Figure 22. To print and punch a source program and delete it from the source, object 
and load libraries 
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SYS1.PR0CLIB 



y 



PCHSORCl * PRTSORCi t SCHLOADT SCHOBJCT SCHSORCE 



5> 4^ 



sTp 



.,_,. PRINT TYPGRG=PO,MAXNAME=1,MAXFLDS=l 

TITLE 1TEM=< 'PRINT OF SOURCE PROGRAM', 48) 



CC7I 
MEMBER NAME=* 



K^PUNCH TYPGRG=PO,MAXNAME-l f CDSEQ»=00000000,MAXFLDS=l 



MEMBER NAME=* 



CC1 



SCHSCRCE 



SCRATCH DSNAME= TEST. SOURCE, VOL=2 3 11= TEST VL,MEMBER=* 



CC1 



SCHLOADT 



SCRATCH DSNAME=TEST.iOAU,VOt=231l=TESTVU, MEMBER** 



CCL 



SCHOBJCT 



SCRATCH DSNAME=TEST.OBJECT,VOL=2311=TESTVL,MEMBER=* 



Figure 23. PRINT, PUNCH, and DELETE 
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SORCEDOC 



SYSt.PROCLIB 



7/SCH1 EXEC PGM=IEhPRGGM 

//DD1 DD VQLUM£=SER=TESTVL,UNIT=2311,DISP=GLD 
4.^ //SYSPRINT 00 SYSUUT=A 

//SYSIN DD DSNAME=SYSl.PRuCLId(SCHSQRCE) ,DISP=GLQ 

// OD DSNAM£=TEMP, VaLUME = SER = TtSJVL,UNIT = 23ll,DISP = GLL>< 





SYSRES 



-S YSi.PROC Ljl' 

JchsorceLL 




CONC 



ATE^ 



OUTPUT DOCUMENT 



SYSTEM SUPPORT .UTILITIES IEHPRUGM 

CCI6 



CC7I 



zrJ 



a. "SCHSGRCfc 

b.| Mi I 

NGKKAl END UF TASK RETURNED FROM SCRATCH 



UTILITY END 



|_ 

SCRATCH. DSNAMfc^TEST. SOURCE , VOL =231 1£TESTVLjMEMBER^*_ 



4. See Figures 22 and 23, the fourth step. 

a. Utility control statement to scratch an unnamed member. The named member is 
found on TEMP, which is concatenated with the control statement. 

b. The concatenated sequential data set containing the member name. 



Figure 24. To concatenate utility control statements 
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LIBRARY BACKUP - AUDIT TRAIL 



Backup Copy 



It is apparent that with such a system as described in this example, a 
means of protection against unforeseen circumstances is mandatory. 



It will be desirable to obtain a "backup" of the TESTS volume as well as 
a listing of its condition at the time a copy is made. The frequency with 
which a backup copy should be made will depend upon the volume of 
testing, but presumably a copy would be made at least once per shift or 
at the end of a large test run where multiple tests were performed. 

The overall procedure for obtaining a backup copy of the TESTS volume 
is shown in Figure 25. Before executing the BACKUP procedure, a 
standard volume label of "BACKUP" must be written on a tape reel, with 
the eleventh byte an EBCDIC zero. ^| rf Cs ;§ £(fik) 

Excluding the listing received from TESTPEEK, Figure 26 illustrates 
the document received when the BACKUP procedure is executed. 



37 



BACKUP 





BACKUP! 



f 



//BACKUP EXEC 
//SYSPRINT 00 
//SYSUTi DO 
//D01 00 
//D02 00 
//SYSIN 00 



P6M=IEHMGVE 

SYSOUT=A 

UNIT=23Ll,VGLUME=SER=illlll,DISP=0Ln 

UNIT=2400»VOLUME=SER=BACKUP,DISP=OL0 

UNIT=23li,VGLUME=SER=TESTVL,0ISP=OLD 

OSNAME=SYS1.PROCLIB< BACKUPl) ,01 SP=OLD 



3. COPY VCLUME=2311=T£STVL,TQ=2400=BACKUP 



TESTVL 




BACKUP 



DOCUMENT 

SEE FIG. 

26 



1. Invokes the BACKUP procedure. 

2. JCL for the BACKUP procedure. 

3. Utility control statement for IEHMOVE. 

4. Invokes the TESTPEEK procedure (see Figure 20). 
A. Overall flow. 



Figure 25. To obtain a backup copy of the TESTS volume 
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SYSTEM .SUPPORT UTILiTIES IEHMOVE 



COPY VOLUME=231 
THE FOLLOWING DATA 
IEJH411I DATA SET TE 
DATA SET TE 




THE FOLLOWING DATA 
IEH41U DATA SET TE 
MEMBR ASUB13 HAS 
MtilBR TEMPNAME HAS 
DATA SET TE 

Thfc FOLLOWING DATA 
1EH4UI DATA SET TE 
MfcMBFi B13 HAS 
MEMBK TEMP HAS 

©DATA SET TE 
^ 



l^TESTVL, T0=2400=BACKUP 

SET IS BEING MOVED. TEST. OBJECT 

ST. OBJECT UNLOADED BECAUSE ACCESS METHOD NOT COMPATIBLE 

ST. OBJECT HAS BEEN COPIED TO VQLUMEIS) 

BACKUP, 0001 

SET IS BEING MOVED. TEST. LOAD 

ST. LOAD UNLOADED BECAUSE ACCESS METHOD NOT COMPATIBLE 

BEEN UNLOADED 

BEEN UNLOADED 

ST. LOAD HAS BEEN COPIED TO VOLUME(S) 

BACKUP, 0002 

SET IS BEING MOVED. TEST. SOURCE 

ST. SOURCE UNLOADED BECAUSE ACCESS METHOD NOT COMPATIBLE 

BEEN UNLOADED 

BEEN UNLOADED 

ST.SQURCE HAS BEEN COPIED TO VOLUMEIS) 

BACKUP, 0003 



A. Note: These are sequence numbers assigned to the data sets on tape. These numbers 
will be used to retrieve the libraries (see Figure 28) . 

Note also that all data sets have been put on tape in an "unloaded" version (C28-6586). 
This is perfectly all right, because, when they are returned to disk, they are returned 
as they were originally. 



Figure 26. Document received from BACKUP procedure 
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Reinitialize TESTS 



If the TESTS volume should be damaged, it must be reinstated to its 
condition at the time the last BACKUP procedure was executed. Since 
this reinitializing will be performed infrequently, the job control state- 
ments to accomplish this are maintained in a card deck rather than in 
SYS1.PROCLIB. 

After a volume has been initialized using DASDI (see Figure 6) , the 
MOVE /COPY utility for data sets will copy the three data sets (source, 
object, load) onto the disk volume (see Figure 27). If additional data 
sets were on the original volume, these could be retrieved at this time 
by reviewing the listing from the BACKUP procedure and observing the 
sequence number of the data set (Figure 26). Figure 28 shows the 
results of this copy of data sets from tape to TESTVL. 

Note: The MOVE /COPY volume utility will MOVE /COPY with direct 
access as the FROM device only . Since FROM (in the MOVE/COPY 
volume utility) may not refer to a non-direct access device such as tape, 
we must use the MOVE /COPY for data sets rather than volume in order 
to retrieve the data sets from tape. 
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COPY BSHAME=TEST . SOURCE > T0=£3 1 1 =TESt VL » FRQf1=£4.0 0= < BACKUP « 03T 
I I I I I I II I I III! 



BSNA*E=TEST . LOAD ? T0=£3 1 1 =TEST VL j FR0M=24 0= < BACKUP < 00 02 > 
I I I I I II I I llll 



COPY BSNAME=TEST . OBJECT » T0=£3 1 1 =TEST VL > FR0M=24 0= < BACKUP « 1 ■' 
I I I I I I I II I I llll 



IN BB * 

ii 



•■'••-'BBS BB UHIT=231 1 > VOLUiiE=SER=TESTVL- BISF-OLB 

II II I III II I 



//BB1 BB" UHIT=2400j VOUJME=SER=BACKUP< BISP=OLB 

II II I II III II I 



••VSYSUTI BB UNIT=231i!.V0LUME=SER=lllllijBISP=aLB 

II I II II I 



'SPRINT' BB 

i ii 



SYSOUT=A 



EXEC PGM=IEHMOVE 
I II I III I 




//RE I N I T JOB 0? 5 1 NSTLMQRK « MSGLEVEL= 1 
II I I I III 

I I II II 111 I I I 

||00 0|00 00000||0|0 0||0|00 0|0|000|00 000000 0000000000000000000000 0000000 00000 

12 3 4 9 6 7 1 9 10 11 12 13 14 15 It 17 H 19 2021 22232425X27 212930 3132 33 34 3539 37 36 39 40 4142 43 44 45 4( 47 M 4< SO SI 52 53 54 5556 57 58 5980 6162 83(4 65 6667 68 69 70 71 72 73 74 7576 77 787960 

I1 1 1 1 1 1 1 1 1 1 1 1 1 ii 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 |n 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ii 1 1 ii i nari 

2222222 2 2 222|22222222|22222|22 |2 22222222222222222222222222222222222222 2 2 22222 22 2 
3333333| 3 3 333333 3313 33 ||33 33|3 33 |333|333 33 333 33333 333 3 3 3333333 33333333 3333 3 3 33 3 3 
4444444444 444444 4444 4444 44 44 4|4444444444 44 444 44444444 4 444444 4444444444 44444444 4-4 
555|5|5555 555555 5555|555555 5 55555|||55 555 55 55 55555555 5555 55 5 55555555555 5555 5555 5 
66666666 666|66 666 66 6 66 6 6||6 66 G6 6 66 666 |66 66 66 6 666 6 66 66 66 6 6 6 66 666B6666666 666666 &6G 
7 7 7777 777 7 7 7 7 7 7 7 7 |7 7 7 7 7 7 7 7 7 7 7 7 7 |7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 
888 8 8888888 8888888|8 888888 8 8 |8 8 8 8 8 8 8 8 |8 8 8 8 8 88 88888888 8888888 888888888 88888888888 
9 9 1 9 1 9 1 9 9 9 9 9 9 9 9 9 9 9 9 1 9 9 9 9 9 S 1 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 S 9 9 9 9 9 9 9 9 

12 3 4 5 6 7 8 9 10 1 1 12 13 14 1516 17 1819 20 2122 2324 25 26 27 28 29 30 31 32 33 34 3536 37 38 39 40 4142 4344 45 46 47 4849 50 51 52 53 54 55 56 57 56 59 60 61 62 6' 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 




OUT PUT 

DOCUMENT 

SEE FIG. 

28 



A. Three COPY utility statements to retrieve the three TESTS libraries. Notice that the 
sequence number (BACKUP, 0001) specification corresponds to the sequence number 
assigned when BACKUP was executed (see Figure 26). 



Figure 27. To reinitialize the TESTS volume 
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SYSTEM SUPPORT UTILITIES IEHMOVE 



© 



COPY DSNAME=TfcST.UBJECT,TO=23il = TESTVL.FRGM = 2400MBACKUP,000l) 
DATA SET TEST. OBJECT HAS BEEN COPIED TO VOLUME! S) 
TESTVL 



COPY DSNAME=TE ST. LOAD, TO=2311=TE ST VL,FROM=2400=( BACKUP. 0002) 
MEMBER ASU313 HAS BEEN MQVED/COPIED , 
MEMBER TEMPNAME HAS BEEN MUVEO/COP I ED. 

DATA SET TEST. LOAD HAS BEEN COPIED TO VOLUME(S) 
TESTVL 



COPY DSN AM£= T ES T. SOURCE, TO=2 3 11= TEST VL ,FROM=2400= ( BACKUP, 0003) 
MEMBER B13 HAS BEEN MOVED/COPIED. 
MEMBfcR TEMP HAS BEEN MOVED/COPIED. 

DATA SET TEST. SOURCE HAS BEEN COPIED TO VOLUME<S) 
TESTVL 



1. Note; Although there were no members in this library, the data set still exists, and 
the original space that had been allocated is still in effect. 

Figure 28. Document received from reinitializing the TESTS volume (see Figure 27 
for execution) 
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MULTIPLE JOB FLOW IN "TESTS" 



Figure 29 illustrates the processing of multiple programs through the 
TESTS environment. The purpose of this figure is to illustrate the 
logical flow, rather than the actual format of the statements. The 
operations involve programs A13, SUBA13, B13, C13, and D13. 

A13 . To be modified and reassembled. 

SUBA13. To be entered as a new source module and link edited with 
A13 to form the new executable module ASUB13. 

B13 . Entered as a new source module to be compiled by COBOL and 
executed. 

C13 and D13 . Both have individually completed the test cycle and are 
to be combined into a new load module (CD13) for execution. Both 
are members of the object and load module libraries and could be 
combined in either format. This example combines the object 
modules. 

The processing illustrated in Figure 29 has been separated into four jobs: 

JOBA enters the source decks into the source library or modifies a 
module already there. 

JOBB assembles or compiles the source modules onto the object 
library. 

JOBC link-edits the object modules into the load library. 

JOBD executes the programs from the JOBLIB (TEST. LOAD) in 
successive job steps. 
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C9/NAME CDI3 


C8/INCLUDE CI3, 


DI3 


C7/NAME ASUBI3 


C6/INCLUDE SUBAI3 


C5/INCLUDE AI3 


C4/NAME BI3 


3/INCLUDE BI3 



EXEC PROC=TESTLINK 



BIO 

B9/V/ SYS IN DD BI3 
B8/7/ EXEC PROC=TESTCOBL 




Figure 29. Job flow of multiple programs from source to execution 
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Job Stream A 

Al. //JOBA JOB 

A2. //EXEC PROC=CHGSORCE 

A3. ./CHNGEA13 

A4. SOURCE for A 13 

AS. //EXEC PROC=NEWSORCE 

A6. ./ADDB13 

A7. B13 

A8. . / ADD SUBA13 

A9. SUBA13 

Job Stream B 

Bl. //JOBB JOB 

B2. //EXEC PROC=TEST ASSM 

B3. //SYSIN DD SUBA13 

B4. //SYSPUNCH DD SUBA13 

B5. //EXEC PROC=TESTASSM 

B6. //SYSIN DD A13 

B7. //SYSPUNCH DD A 13 

B8. //EXEC PROC=TESTCOBL 

B9. //SYSIN DD B13 

BIO. //SYSPUNCH DD B13 

Job Stream C 

CI. //JOBC JOB 

C2. //EXEC PROC=TESTLINK 

C3. INCLUDE B13 

C4. NAMEB13 

C5. INCLUDE Al 3 

C6. INCLUDE SUBA13 
C7. NAME ASUB13 (R) 



C8. INCLUDE (C13,D13) 

(Performs same function 
as C5 and C6) 

C9. NAMECD13(R) 



Job Stream D 

Dl. //JOBDJOB 

D2. //JOBLB DD TEST. LOAD 

D3. //EXEC PGM=ASUB13 

(DD statements for ASUB13 
not shown) 

D4. //EXEC PGM=B13 

(DD statements for B13 not shown) 

D5. //EXEC PGM=CD13 

(DD statements for CD13 
not shown) 

Figure 29 (continued). 



Processing Incurred 

Job statement indicating start of JOBA. 

Invokes the cataloged procedure to update programs already on the source library. 

Indicates the name of the program (A13) to be updated in the source library. 

The source statements which will update A13. 

Invokes the cataloged procedure to enter new programs in the source library. 

Indicates the name of the program (B13) to be added to TEST. SOURCE. 

The deck of source statements comprising B13. 

(See A6. ) In this case SUBA13 is the new subroutine to be added to TEST. SOURCE. 

Source statements for SUBA13. 

Specifies JOBB, in this application the language translation. 

Invokes the cataloged procedure for Assembler. 

Represents the DD statement which specifies the name of the module (SUBA13) to be assembled. 

Specifies to the assembler the name (SUBA13) to be given the output module on the object library. 

(See line B2. ) Second job step. 

(See B3. ) In this case, program A13 which has just been modified is to be recompiled. 

(See B4. ) The new object module will replace the one named A13 previpusly placed in the 
object library. 

Invokes the cataloged procedure for COBOL. 

Specifies that the name of the COBOL source module to be compiled is B13. 

Specifies that B13 is the name to be assigned to the compiled object module. 

Processing Incurred 

Job statement-start of JOBC. In this case, only one job step occurs. 

Invokes the cataloged procedure to link-edit object modules into load modules. 

Linkage Editor control statement indicating that the name of the first object module to be link 
edited is B13. 

Specifies that the resultant new load module which becomes a member of TEST. LOAD is to be 
named B13. 

Linkage Editor control statement indicating that the second object module to be link-edited is 
called A13. 

(See C5. ) Indicates that SUBA13 is to be link-edited with A13. 

Specifies that the resultant load module consisting of A 13 and SUBA13 is to be entered into 
TEST. LOAD and ASUB13. 



Linkage Editor control statement indicating that the input for this load module will be object 
modules C13 and D13. 

Linkage Editor control statement specifying the resultant load module consisting of C13 and D13 
should be entered on TEST. LOAD as CD13. 



Job statement indicating start of JOBD. 

JOBLIB points to the library, TEST. LOAD, containing the programs to be executed in this job step. 

Specifies that the first job step will execute program ASUB13, followed by the appropriate DD 
statements defining the input and output data sets for this program. 

The second job step will execute program B13. (See line 3. ) 

The third job step will execute program CD13. (See line 3. ) 
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